True unicast streaming has lost his appeal

I set up this website in 2012 in order to learn something more about streaming.
I was - and am - convinced that streaming over the web is the future of media transmission.
Radio broadcasting (as we know, with the viewer sat in front a television looking what the broadcaster want she/he watch) is going to finish, as it is already finished for the greater part of young people.
With many other thousands I use to think this already 20 years ago.

Despite of this, coming from broadcasting television environment, it sound me quite crazy to use unicast for everything: at least for live events the multicast could be used.
I mean, instead of creating millions independent streams, one for each viewer couldn't we use multicast at least for live events? We should break the mafia of multicast forbidders, but maybe it could.
You cannot stream in multicast because the multicast addresses (The D class, 224-239 range of A class) is reserved to registered users, and - as for IPv4 - 250 millions of multicast addresses quickly finished.

Once upon a time (as in the children's stories), and still today, is possible to stream in true http stream - anyhow in unicast - instead of downloading to the viewer's system a copy (sliced or not) of what she/he is watching.
We used to call it progressive download, now we call it HLS or DASH, but it's only a way to copy locally the content (sliced, encrypted or not).

The intelligence of network could allow us to transmit once and view many times, excluding the repetitions (that unavoidably happens).
This can be done as I do on this website, using videolan VLC as generator and the streaming server (in my case apache) to perform the reverse proxying.
What I do is simply produce the stream with videolan VLC on improbable port (e.g. around 64000) and ask to the web server to forward it outside on port 80.

The biggest problem is that to play these streams you must use the VLC plug-in external to the browser, a practice discouraged by html5, that prefere to deal with browser's decompression capability through the <video> or <audio> tags.

The ufficial reason for this end has been a safety bug found in VLC in 2017.
This bug might be dangerous only in case VLC would not be installed but "cloned", as it should had not be done (through the plain installaion the bug did not exist).
The safety hole was quickly repaired but anyhow the VLC plug-in was blamed by all the browsers.
First was Chrome, followed by Opera and then by Firefox (version 52 march 7th, 2017); last Internet Explorer.
It could seem that only Apple Safari for windows avoids to be part of this crazy choir, but the reason was simple: safari for windows had no more maintenance after 2015.

At the moment the most common browsers (Chrome, Firefox, Opera, Edge) are able to reproduce h264+aac/mp3 within mp4 wrapper or vp8+ogg within a webm wrapper, as stated by W3C in<video> and <audio> tags definition.
It is quite useless to search for minor browsers (such as Midori browser), which initially seems in continuing to support VLC plug-in. But the lack of support and the single browser story (Midori is/was an open source porting from Linux) left quickly without maintenance. Practically quickly these alternatives do not work.

Special versions of more used browsers

I've seen the hint to use firefox ESR version (that stated for Extend Support Release, not fully updated for big organizations).
It anyhow refers to the usage of flash plug-in, and - as written in this support note - in 2019 (after late 2018) all the plug-ins will no more supported. Coherently from the name: Extended Support Release...

This is not a valid solution

... and what would happen with next compression schemes?

is this solution future proof ?
What will happen with next compression schemes ?
From 1988 we passed through MPEG1. MPEG2, MPEG4 (including h264), HEVC, now we are waiting JVET. The solution adopted by the leading browsers of supporting directly only h264 seem of short life, say: no more that 10 years.

As typically happens over the web you're free to do whatever you want, simply build-up your own browser as frequently happens in the greater part of the apps for smartphones (practically browsers that opens only one website).

Use of former versions of de facto standard browsers

So, why do not use a former version of the many available de-facto standard browser?
In this support note Mozilla warmly descourage this, but - maybe - it could be better to use a general purpose browser instead of developing our own. (Queste raccomandazioni sono disponibili anche in italiano).

If you want to try with firefox, once reached the support page, look for the latest 51th version: as of writing it is the 51.0b9 available for 32 bit as well for 64 bit in many languages.
In the directory you can choose the installer or the stub (the link to download it later).
If you are a firefox user (or simply you've already installed the last version of firefox), during the installation specify a different directory (such as program files\firefox51) and do not check the 51 as default browser.
At the first run check out the auto update for 51 in order to avoid to automatically update the 51 to the latest version.

As said above it is not possible to run symultaneously the two different versions on the machine, but is possible to use them as you want.
If you run the latest version while is running the 51, it will be open a new instance of 51, not the latest (at least on my windows 7 home)
Be careful to have correctly intalled the VLC plug-in: as it happened to me, installing many version VLC on the same computer, the register was not correctly set and the systems was unable to find the plug-in.

The image is a composition of the two views of the same page with two versions of the same browser.
As you can see in this screenshot (taken before I added an escape image to the webpage) in the 66 version the embed area simply disappear.
The shown page is http://www.iginomanfre.it/html/CIF_284.html that embeds the stream http://iginomanfre.it/CIF_284

For your commodity this is (better: could be) the same video of
http://www.iginomanfre.it/html/CIF_284.html
shown above
(stream http://iginomanfre.it/CIF_284)